「AWS Client VPN エンドポイントで DNS はどのように機能しますか?」を図に書き起こして理解してみた
コンバンハ、千葉（幸）です。
AWS ナレッジセンターの記事の一つに、AWS Client VPN における DNS の挙動について説明したものがあります。 Client VPN 接続時に参照する DNS サーバーや、その構成における考慮点などが記載されています。
ちょうど似たようなケースで詰まっていたこともあり、喜んで参照したのですが、如何せん……頭の中で図がうまく描けない。すごく大事なことが書いてある気がするのに……理解が追いつかない。
ページにおいては、シナリオごとに異なる前提の構成が記載されており、それらのパターンに応じた挙動が説明されています。脳内でうまいこと処理できれば良かったのですが、私の脳に搭載しているマシンのスペックでは難しそうです。
ということで、脳の外で図に描き起こして理解することにしました。折角描いたので共有します。
目次
補足
- 記載内容については元のページを正としてください
- AWS Client VPN エンドポイントのパラメータ「DNS サーバーの IP アドレス」について、本エントリではカスタム DNS サーバーと記載します
- そのほうがパラメータ名っぽいからです
カスタム DNS サーバーに関する考慮事項
元のページで記載されている内容をできるだけ噛み砕いて書き直します。
また、内容すべてをカバーするものではありませんが、用語の整理も兼ねて簡単なイメージ図を載せておきます。
- カスタム DNS サーバーは高可用性のために 2 つ設定することがベストプラクティスです
- プライマリに到達できない場合、セカンダリに DNS クエリを送信します
- ただし プライマリが「SERVFAIL」で応答した場合にはセカンダリには送信しません
- クライアントデバイスが Client VPN エンドポイントに接続した後に、 DNS サーバーに到達できる状態であるかを意識してください
- カスタム DNS サーバーを2つ設定した場合は、その両方に到達できるようにしてください
- カスタム DNS サーバーはオプションであり、設定しないこともできます
- その場合、クライアントデバイスにもともと設定されていた DNS サーバーを使用します
- カスタム DNS サーバーとして Amazon Provided DNS もしくは Route53 Resolver インバウンドエンドポイントを指定する場合、以下の挙動になります
- VPC に関連づけられた Route 53 プライベートホストゾーンのリソースレコードを解決できる
- RDS パブリックホスト名、AWS サービスエンドポイント名（ VPC インタフェースエンドポイント設定済みのもの）を名前解決するとプライベートIP アドレスが返却される
- ただし VPC で「DNS 解決」「DNS ホスト名」が有効の場合に限る
- Client VPN エンドポイントを経由して VPC 内（あるいはそこと接続された環境）のリソースにアクセスする際、送信元 NAT が行われます
- スプリットトンネルが無効（フルトンネル）であっても有効であっても、カスタム DNS サーバーはクライアントデバイスに適用されます
- フルトンネルの場合、VPN トンネルが確立したのち、すべてのトラフィックがトンネルを経由することになります
- DNS トラフィックもトンネルを経由することになるため、DNS サーバーに到達できるようターゲットネットワーク（サブネット）の設定、Client VPN ルートテーブルの設定を意識してください
- スプリットトンネルの場合、VPN トンネルが確立したのち、Client VPN ルートテーブルに存在する宛先へのトラフィックがトンネルを経由することになります
- ピアリング先の VPC、接続先のオンプレなどに DNS サーバーがある時には、そこに向けたルートを忘れずに Client VPN ルートテーブルに追加してください
シナリオ#1 カスタム DNS サーバー無効のフルトンネル
以下設定の Client VPN エンドポイントに接続した際のシナリオです。
- カスタム DNS サーバー：無効
- スプリットトンネル：無効
シナリオの中で、2パターンあります。
例1 ローカル DNS サーバーを参照している場合
以下のような前提です。
- クライアントデバイスはローカルの DNS サーバを参照している
- そこに向けた静的ルートが定義されている
この前提で Client VPN エンドポイントに接続した際の挙動としては以下のようになります。
- カスタム DNS サーバーが無効のため、ローカルの DNS サーバーを参照し続ける
- フルトンネルのため、デフォルトルートが Client VPN トンネルを向く
- 静的ルートが定義済みのため、ローカル DNS サーバ向けの通信はトンネルを経由しない
上記から、ローカル DNS サーバーで名前解決したのち、対象の宛先へ VPN トンネル経由でアクセスする、という挙動となります。
以下、Client VPN 接続後の各コマンドの実行結果です。（元のページより引用）
参照先の DNS サーバーはローカルのもののままです。
$ cat /etc/resolv.conf | grep nameserver nameserver 192.168.1.1
クライアントデバイスのルートテーブルで、ローカル DNS サーバーへの静的ルートが定義されています。（-Eは正規表現を使用するオプション。ここでは「utun1もしくは192.168.1.1を含む」を意味します。）
$ netstat -nr -f inet | grep -E 'utun1|192.168.1.1' 0/1 192.168.0.1 UGSc 16 0 utun1 192.168.1.1/32 link#4 UCS 1 0 en0 (...)
名前解決が問題なく行えます。（名前解決した宛先へのアクセスは VPN トンネル経由となります。ここではグローバル IP へのアクセスとなるため、ターゲットネットワークからインターネット疎通可能な状態である必要があります。）
$ dig amazon.com ;; ANSWER SECTION: amazon.com. 32 IN A 176.32.98.166 ;; SERVER: 192.168.1.1#53(192.168.1.1) (...)
例2 パブリック DNS サーバーを参照している場合
以下のような前提です。
- クライアントデバイスはパブリック DNS である 8.8.8.8 を参照している
- そこに向けた静的ルートは定義されていない
この前提で Client VPN エンドポイントに接続した際の挙動としては以下のようになります。
- カスタム DNS サーバーが無効のため、8.8.8.8 の DNS サーバーを参照し続ける
- フルトンネルのため、デフォルトルートが Client VPN トンネルを向く
- 8.8.8.8 宛の DNS ルックアップの通信も VPN トンネルを経由する
上記から、名前解決を試みる際には、 VPN トンネルを経由し、ターゲットネットワークの ENI から 8.8.8.8 への通信を試みます。ターゲットネットワークがインターネット疎通可能な状態に構成されていない場合、 DNS ルックアップは失敗します。
このシナリオでは、ターゲットネットワークからインターネットへの疎通ができるように構成されていないケースが想定されています。
以下、Client VPN 接続後の各コマンドの実行結果です。（元のページより引用）
参照先の DNS サーバーは 8.8.8.8 のままです。
$ cat /etc/resolv.conf | grep nameserver nameserver 8.8.8.8
8.8.8.8 に向けた静的ルートはありません。
$ netstat -nr -f inet | grep -E 'utun1|8.8.8.8' 0/1 192.168.0.1 UGSc 5 0 utun1
名前解決を試みると、 DNS サーバーに到達できずタイムアウトします。
$ dig amazon.com (...) ;; connection timed out; no servers could be reached
この例と似たようなケースを取り上げたエントリもありますので併せてご参照ください。
シナリオ#2 カスタム DNS サーバー有効のスプリットトンネル
以下設定の Client VPN エンドポイントに接続した際のシナリオです。
- カスタム DNS サーバー：有効
- スプリットトンネル：有効
こちらのシナリオのパターンは 1 つです。
例 対向 VPC の Route 53 リゾルバ Inbound Endpoint を参照する場合
以下のような前提です。
- Client VPN エンドポイントを関連付けた VPC と対向の VPC が Transit Gateway で接続されている
- 対向 VPC は以下の構成となっている
- Route 53 リゾルバ Inbound Endpoint が作成されている
- Route 53 プライベートホストゾーンが関連づけられている
- 「DNS ホスト名」および「DNS サポート」が有効になっている
- Client VPN エンドポイントのカスタム DNS サーバーでは上記の Inbound Endpoint の IP アドレスが設定されている
- Client VPN エンドポイントルートテーブルでは対向 VPC に向けたルートが定義されている
この前提で Client VPN エンドポイントに接続した際の挙動としては以下のようになります。
- カスタム DNS サーバーが設定されているため、 DNS サーバーとしてリゾルバ Inbound Endpoint の IP アドレスがプッシュされる
- スプリットトンネル有効のため、対向 VPC に向けたルートがクライアントデバイスにプッシュされる
- DNS ルックアップの通信は VPN トンネルを経由する
以下、Client VPN 接続後の各コマンドの実行結果です。（元のページより引用）
クライアントデバイスのルートテーブルには、以下がプッシュされています。
- Client VPN エンドポイントを関連づけた VPC の CIDR
- 対向 VPC の CIDR
$ netstat -nr -f inet | grep utun1 (...) 10.10/16 192.168.0.1 UGSc 2 0 utun1 # Route 53 Resolver inbound endpoints VPC CIDR 10.123/16 192.168.0.1 UGSc 0 0 utun1 # Client VPN VPC CIDR (...)
カスタム DNS サーバーで指定している IP がクライアントデバイスにプッシュされ、参照先の DNS サーバーが変更されています。
$ cat /etc/resolv.conf | grep nameserver nameserver 10.10.1.228 # Primary DNS server nameserver 10.10.0.43 # Secondary DNS server
この DNS サーバーに到達可能なように各種ルートや Firewall の設定がなされていれば、クライアントデバイスは問題なく名前解決を行えます。
Route 53 リゾルバ Inbound Endpoint が名前解決できるもの
今回の構成において、 Inbound Endpoint がフルサービスリゾルバとしてどのようなものを名前解決できるかを確認します。
通常通り、パブリックなドメイン名からパブリック IP を引くことができます。
$ dig amazon.com ;; ANSWER SECTION: amazon.com. 8 IN A 176.32.103.205 ;; SERVER: 10.10.1.228#53(10.10.1.228) (...)
対向 VPC に関連づけられた プライベートホストゾーンから IP を引くことができます。
$ dig test.example.local # Route 53 private hosted zone record ;; ANSWER SECTION: test.example.local. 10 IN A 10.123.2.1 ;; SERVER: 10.10.1.228#53(10.10.1.228) (...)
一部の AWS サービスエンドポイントから、プライベート IP を引くことができます。一部とは、「 対向 VPC 上でVPC エンドポイント（インタフェース型）が作成されているもの」を指します。
$ dig ec2.ap-southeast-2.amazonaws.com # VPC interface endpoint to EC2 service in Route 53 Resolver VPC ;; ANSWER SECTION: ec2.ap-southeast-2.amazonaws.com. 60 IN A 10.10.0.33 ;; SERVER: 10.10.1.228#53(10.10.1.228) (...)
対向 VPC 上に存在する EC2 インスタンスのパブリック DNS 名から、プライベート IP を引くことができます。
$ dig ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com # EC2 instance public DNS hostname running in Route 53 Resolver VPC ;; ANSWER SECTION: ec2-13-211-254-134.ap-southeast-2.compute.amazonaws.com. 20 IN A 10.10.1.11 ;; SERVER: 10.10.1.228#53(10.10.1.228) (...)
終わりに
ナレッジセンターの記事を図解して理解してみました。書いてみてようやく理解が追いつきました。
特に、シナリオ 2 の Route53 プライベートホストゾーンの関連づけ先は、ずっと Client VPN エンドポイントを関連づけた VPC だと捉えていました。
少なくとも リゾルバ Inbound Endpoint が存在する VPC にも関連づいていないときちんと引けないよな、ということは図を書いてようやく思い至りましたので、やってみた価値はあったかと思います。
私の脳だけでなく、どなたかの脳のに対しても参考になれば幸いです。
以上、千葉（幸）お送りしました。
